Not sure if it is a good idea. Historically pyexasol was slightly incompatible with DB API 2.0 on purpose. It forced users to look at documentation for a few minutes instead of mindlessly copying incorrect advice from StackOverflow.

Main issues with DB API 2.0:

• designed a long time ago;
• designed for OLTP databases running on a single node;

Fundamentally implementing it would cause more harm than good.

Hi @littleK0i,

I understand and share your concern. That is why I made the shim a separate package. It won't even be part of the pyexasol namespace. If you think the docs may lure some folks into just copying the example without reading it, we could put the part on the alternatives at the end of the document.

Why we are doing this?

We have seen use cases and received requests in the past where DBAPI2 compliance was desired and reasonable, or the only way to integrate with other frameworks. Therefore, we believe we should allow users to achieve this. Although there is turbodbc, it is not a viable alternative in all cases, particularly since it is ODBC-based.

In the end, it is up to the user and their needs. I do not see why we should patronize the library users. We should make the right things easy and the potentially harmful ones harder, but ultimately the user should be able to decide because they should know what they need.

Fundamentally implementing it would do more harm than good.

Having worked intensively with C++ in the past (8+ years) 😬, I totally understand where you're coming from.
However, we strongly believe that this change will be beneficial for some users.

Nevertheless, any suggestions and discussions are welcome so that we can enable the user to make a well-informed decision about the potential tradeoffs at hand.

I hope this helps to better understand the background of this change.
Looking forward to getting further feedback from your side.

best
Nico

🗒️ Side note:
Initially, we considered making it an "undocumented feature". However, finally we where not convinced about this idea because having it undocumented would mean we cannot document the pros and cons (enable the user).

@littleK0i

I'll merge this PR for now. If you have any further feedback or feel that I may have been too quick with this change, please feel free to contact me directly via email. Your feedback is always highly appreciated and welcome.

Best,
Nico